Солдатов в Телеграм

Эффектное тестирование

В прошлый раз мы обсуждали гибкую разработку и наметили узкое место - тестирование и дефекты. Решение этой проблемы предлагает сам процесс промышленной разработки - рассмотрим его в паре предложений. Заказчик готовит бизнес-требование, где с возможной для себя детализацией описывает, что он хочет. Далее, требование попадает к системному аналитику, который это требование анализирует - декомпозирует на понятные короткие требования, детально прописывает весь функционал, все пользовательские сценарии, согласует все с заказчиком - получается документация. Фактически "документация" - это отражение бизнес-требования заказчика, согласованное с ним. Вся дальнейшая работа ведется с этой документацией.

Документация идет в разработку, разработчик реализует то, что написано в документации. Тестировщик пишет сценарии тестирования, опираясь на пользовательские сценарии, изложенные также в документации. Тестовый сценарий выглядит так: описание действий, ожидаемый результат, а дефект (баг) - это когда выполняются описанные в тестовом сценарии действия, но полученный результат не совпадает с ожидаемым. По-моему все просто замечательно! Описание тестирования гарантирует повторяемость (а это уже зрелость не ниже второго уровня!), что такое баг - четко определено. Если находится проблема в пользовательском сценарии, не указанном в документации, - это не баг, а фича (действительно, пользовательский сценарий не описан в документации, согласованной с заказчиком, а значит его не должно быть). Там, где нет тестового сценария, проблема не ищется, а, следовательно, не находятся. Меньше дефектов - результативнее разработка.

#пятница #dev

www.tg-me.com/ru/Солдатов в Телеграм/com.soldatov_in_telegram/670

969 viewsJun 6 at 08:11

Эффектное тестирование

В прошлый раз мы обсуждали гибкую разработку и наметили узкое место - тестирование и дефекты. Решение этой проблемы предлагает сам процесс промышленной разработки - рассмотрим его в паре предложений. Заказчик готовит бизнес-требование, где с возможной для себя детализацией описывает, что он хочет. Далее, требование попадает к системному аналитику, который это требование анализирует - декомпозирует на понятные короткие требования, детально прописывает весь функционал, все пользовательские сценарии, согласует все с заказчиком - получается документация. Фактически "документация" - это отражение бизнес-требования заказчика, согласованное с ним. Вся дальнейшая работа ведется с этой документацией.

Документация идет в разработку, разработчик реализует то, что написано в документации. Тестировщик пишет сценарии тестирования, опираясь на пользовательские сценарии, изложенные также в документации. Тестовый сценарий выглядит так: описание действий, ожидаемый результат, а дефект (баг) - это когда выполняются описанные в тестовом сценарии действия, но полученный результат не совпадает с ожидаемым. По-моему все просто замечательно! Описание тестирования гарантирует повторяемость (а это уже зрелость не ниже второго уровня!), что такое баг - четко определено. Если находится проблема в пользовательском сценарии, не указанном в документации, - это не баг, а фича (действительно, пользовательский сценарий не описан в документации, согласованной с заказчиком, а значит его не должно быть). Там, где нет тестового сценария, проблема не ищется, а, следовательно, не находятся. Меньше дефектов - результативнее разработка.

#пятница #dev

BY Солдатов в Телеграм